…creen

Root cause was two-layered:

1. resetToPasswordFlow() reset authFlow to FLOW.PASSWORD but also cleared
   user_name/user_pic/user_fullname/user_verified in the same setState call.
   isPasswordFlow's render condition requires user_verified === true, so
   wiping it forced the render logic to showDefaultFlow (the email screen)
   regardless of authFlow being correct.

2. That alone wasn't sufficient: since the password step now submits as a
   native form POST (see the earlier native-submit fix), the mfa_required
   transition is a full page reload, not a client-side setState - the React
   app remounts from scratch and only recovers state the backend flashed to
   session. issueChallenge() (EmailOTPMFAChallengeStrategy/AbstractMFA
   ChallengeStrategy) only returns otp_length/otp_lifetime, so
   challengeRequired()'s session flash never carried username/user_fullname/
   user_pic/user_verified in the first place - user_verified was already
   false the moment the 2FA screen first rendered, before Cancel was ever
   clicked. Fix #1 alone had nothing to preserve.

Fix: postLogin()'s mfa_required branch now merges the same identity fields
into the challengeRequired() payload that the AuthenticationException
errorLogin() branch already flashes (same fields, same getters: username,
user_fullname, user_pic, user_verified, user_is_active) - restoring the
identity chip on the 2FA screen and giving resetToPasswordFlow() correct
state to preserve. resetToPasswordFlow() no longer clears user_name/user_pic/
user_fullname/user_verified.

Verified live: 2FA screen now shows the identity chip from first render:
Cancel from the 2FA screen now returns directly to the password screen with
the same user still identified, instead of resetting to the email-entry
screen. tests/TwoFactorLoginFlowTest.php passes in full (31 tests, 120
assertions) - unaffected, since no test asserted the previously-missing
identity fields.

handleDelete() (the login page's identity chip "x") reset client-side
state but never called cancelLogin(), unlike the explicit "Cancel" link
(resetToPasswordFlow()). During the 2fa/recovery screens this left the
pending 2fa_pending_user_id session state and the issued OTP alive
server-side until the session TTL, instead of being invalidated
immediately like Cancel does.

PR #142 review finding #1.

…resh

The session stored otp_lifetime as a static duration, so any mid-challenge
GET /login re-seeded the countdown with the FULL TTL - a user refreshing
4 minutes into a 5-minute challenge saw a fresh 5:00 countdown for a code
the server would reject much sooner, letting them burn the 2fa.rate:verify
attempt window (3 failures / 15 min lockout) on a code the UI claimed was
still valid.

issueChallenge() now also returns otp_issued_at taken from the OTP
entity's created_at - the same source isAlive()/getRemainingLifetime()
use server-side, so the countdown can never drift from the actual expiry
check (a controller-side time() stamp would land after issuance and
overstate the remaining window). The timestamp rides the same
challengeRequired()/session mechanism as otp_length/otp_lifetime, is kept
in sync on resend, cleared with the rest of the MFA UI state, and the
blade seeds config.otpLifetime with max(0, lifetime - elapsed).

RED verified before the fix: the new reproducer rendered the full TTL
(600) instead of the remaining ~500. Full TwoFactorLoginFlowTest suite
green: 32 tests, 140 assertions.

PR #142 review finding LOW #1.